%\subsubsection*{Background and Assumption}
\section{\large Background of Testing-based Bug Localization}
\label{sec:background}

We next briefly introduce the background and terminologies
in testing-based bug localization.

A software system $S$ consists of a set of statement $stmts$; each
statement in $stmts$ takes a set of program variables, performs certain
computation, and assigns computed values to the output program variables.  
A bug occurs when a statement in $stmts$ assigns incorrect value to one
or more of its output program variables, and that incorrect output
variable is later used by other statements. A single statement can be executed
multiple times before a bug becomes apparent. Thus, a bug localization
technique must handle such cases.

 Various kinds of data are gathered through software development.
\textit{Testing data} is particularly common and valuable to localize
bugs in practice.
%Our technique utilizes the \textit{testing data} to localize bugs. 
Given a test suite $T$ for a software system $S$, a test case $t$
in $T$ exercises a subset of $stmts$, and gives test execution
result: pass/fail and code coverage information.

%our technique requires two types of information about the
%execution of $S$ with $t$: pass/fail results and code coverage. 

A test case $t$ passes if the actual output for an execution of $S$ with
$t$ is the same as the expected output for $t$; otherwise, $t$
fails. The code coverage for $t$ consists of the source-code
statements that are executed when $S$ is run with $t$. Thus, within the scope
of testing-based bug localization, for a certain technique, the input normally
consists of three components: the source
code for $S$; the pass/fail results for executing $S$ with each $t$
in $T$ ; and the code coverage of executing $S$ with each $t$ in
$T$.  The test suite $T$ may contain one or more failing tests, which indicate
potential bugs in the tested software. The output is
a ranked list suspicious statements that are likely to be buggy.
